home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / Extras / IFF / IFF_Forms / DEEP.doc < prev    next >
Encoding:
Text File  |  1993-03-01  |  7.0 KB  |  318 lines
  1. Chunky pixel image files (Used in TV Paint)
  2.  
  3. IFF FORM / CHUNK DESCRIPTION
  4. ============================
  5.  
  6. Form/Chunk ID:    FORM  DEEP    (DEEP pixels)
  7.         Chunk DGBL    (Deep GloBaL information)
  8.         Chunk DPEL    (Deep Pixel ELements)
  9.         Chunk DLOC    (Deep display LOCation)
  10.         Chunk DBOD    (Deep data BODy)
  11.         Chunk DCHG    (Deep CHanGe buffer)
  12.  
  13. Date Submitted:    10-Sep-91
  14. Submitted by:    Amiga Centre Scotland
  15.  
  16.  
  17. FORM
  18. ====
  19.  
  20. FORM ID:    DEEP    (DEEP pixels)
  21.  
  22. FORM Purpose:
  23.  
  24. To allow faster loading and saving of images when pixels are
  25. stored in consecutive memory locations and provide support for
  26. common extensions implemented on advanced graphics cards.
  27.  
  28. FORM Description:
  29.  
  30. This form is designed to provide support for a variety of deep
  31. pixels, including 24 bits images.  A deep pixel is one in which
  32. the pixel value is used to directly produce the output colour
  33. without the use of a colour look-up table and also where the
  34. pixel is stored in consecutive memory locations.  The format
  35. allows additional bits to be stored along with the colour bits
  36. to provide support for additional features such as masks,
  37. Z-buffers, linear keys, etc.
  38.  
  39. The format is designed to allow different colour formats to be
  40. stored such as RGB, RGBA, YCM and YCMB with varying depths
  41. supported.  Bit ordering will be most significant bit first.
  42.  
  43.  
  44. CHUNKS
  45. ======
  46.  
  47. Chunk ID:    DGBL    (Deep GloBaL information)
  48.  
  49. Chunk Purpose:
  50.  
  51. Provide global information of relevance to all the data contained
  52. in the file.  DGBL will always be the first chunk in the file.
  53.  
  54. Chunk Description:
  55.  
  56. Used to provide information that is constant for all contents of
  57. the file.  One chunk is mandatory at the start of the file.  When
  58. the file is used to store a group of images it may, in
  59. exceptional circumstances, be necessary to add additional DGBL
  60. chunks.  The contents of a DGBL chunk remain valid until another
  61. DGBL chunk is encountered.
  62.  
  63.  
  64. Chunk ID:    DPEL    (Deep Pixel Elements)
  65.  
  66. Chunk Purpose:
  67.  
  68. Defines the contents of each pixel.  Enables the data content to
  69. be identified and handled.  Data that is unknown or not required
  70. can be discarded.
  71.  
  72. Chunk Description:
  73.  
  74. This chunk is best described by an example:
  75.  
  76.     Original data = RGBA 8:8:8:4
  77.  
  78.     DPEL =
  79.         4    (number of elements)
  80.             RED    (first element)
  81.             8    (bits in element)
  82.             GREEN    (second element)
  83.             8    (bits in second element)
  84.             BLUE    (third element)
  85.             8    (bits in third element)
  86.             ALPHA    (fourth element)
  87.             4    (bits in fourth element)
  88.  
  89.     Stored data (binary) = rrrrrrrr gggggggg bbbbbbbb aaaa0000
  90.  
  91.   Note:  The pixel has been padded to the next byte boundary.
  92.  
  93. The elements must be defined in the order in which they are
  94. stored, with the most significant bit first.
  95.  
  96.  
  97. Chunk ID:    DLOC    (Deep display LOCation)
  98.  
  99. Chunk Purpose:
  100.  
  101. Provides information specific to the following DBOD section.
  102. Enables image sections to be located within the screen area
  103. individually & allows images with a size different to
  104. DisplayWidth & DisplayHeight to be stored.
  105.  
  106. Chunk Description:
  107.  
  108. Specifies the width, height and where to place the following Deep
  109. data BODy.  If no DLOC is encountered before a DBOD, the
  110. DisplayWidth & DisplayHeight parameters will be used as the DBOD
  111. image data dimensions.  The contents of a DLOC chunk remain valid
  112. until another DLOC chunk is encountered.
  113.  
  114.  
  115. Chunk ID:    DBOD    (Deep BODy)
  116.  
  117. Chunk Purpose:
  118.  
  119. Contains the image data.
  120.  
  121. Chunk Description:
  122.  
  123. Contains image data compressed by the method defined in DGBL.
  124. The image size and the location where it is to be displayed is
  125. provided by a DLOC chunk.  If no DLOC chunk has been read the
  126. data will be displayed in the upper left corner and will be
  127. DisplayWidth wide and DisplayHeight high.
  128.  
  129.  
  130. Chunk ID:    DCHG    (Deep CHanGe buffer)
  131.  
  132. Chunk Purpose:
  133.  
  134. Informs the IFF reader that a complete frame has been read.  Only
  135. required when multiple images are stored for cell animation.
  136.  
  137. Chunk Description:
  138.  
  139. When a DCHG chunk is encounter the IFF reader knows that a
  140. complete frame has been read.  The chunk gives the time *from the
  141. last frame change* before the frame should be changed again.  If
  142. the time has already elapsed the frame should be changed
  143. immediately.  A FrameRate of 0 will cause the frame changes to
  144. occur as fast as possible.  A FrameRate of -1 is used to indicate
  145. the end of the data for one frame and the start of the next in
  146. cases where multiple frames are stored but are not intended for
  147. animation.  A DCHG chunk is not required when only a single frame
  148. is stored.
  149.  
  150.  
  151.  
  152. //
  153. //FORM DEEP
  154. //=========
  155. //
  156. //  Chunk DGBL
  157. //  ----------
  158. //
  159.     struct DGBL = {
  160. //
  161. // Size of source display
  162. //
  163.       UWORD  DisplayWidth,DisplayHeight;
  164. //
  165. // Type of compression
  166. //
  167.       UWORD  Compression;
  168. //
  169. // Pixel aspect, a ration w:h
  170. //
  171.       UBYTE  xAspect,yAspect;
  172.     };
  173.  
  174. //
  175. //   Chunk DPEL
  176. //   ----------
  177.     struct DPEL = {
  178. //
  179. // Number of pixel components
  180. //
  181.     ULONG nElements;
  182. //
  183. // The TypeDepth structure is repeated nElement times to identify
  184. // the content of every pixel.  Pixels will always be padded to
  185. // byte boundaries.  The DBOD chunk will be padded to an even
  186. // longword boundary.
  187. //
  188.     struct TypeDepth = {
  189. //
  190. // Type of data
  191. //
  192.       UWORD cType;
  193. //
  194. // Bit depth of this type
  195. //
  196.       UWORD cBitDepth;
  197.       } typedepth[Nelements];
  198.     };
  199.  
  200. //
  201. //  Chunk DLOC
  202. //  ----------
  203. //
  204.     struct DLOC = {
  205. //
  206. // Body width & height in pixels
  207. //
  208.       UWORD    w,h
  209. //
  210. // Pixel position for this image
  211. //
  212.       WORD    x,y
  213.     };
  214.  
  215. //
  216. //  Chunk DBOD
  217. //  ----------
  218. //
  219.     pixel[0], pixel[2], pixel[3], ...., pixel[w-1]
  220.     pixel[((h-1)*w)], ...,pixel[h*w-1]
  221.  
  222. //
  223. //  Chunk DCHG
  224. //  ----------
  225. //
  226.     struct DCHG = {
  227. //
  228. // Animation control (When multiple images are stored)
  229. // FrameRate - milli-seconds between frames changes
  230. //
  231.       LONG  FrameRate;
  232.     };
  233.  
  234. Compressions currently defined:
  235.  
  236. NOCOMPRESSION    =    0
  237. RUNLENGTH    =    1
  238. HUFFMAN        =    2
  239. DYNAMICHUFF    =    3
  240. JPEG        =    4
  241.  
  242. Ctype currently defined:
  243.  
  244. RED        =    1
  245. GREEN        =    2
  246. BLUE        =    3
  247. ALPHA        =    4    (no precise definition of use)
  248. YELLOW        =    5
  249. CYAN        =    6
  250. MAGENTA        =    7
  251. BLACK        =    8
  252. MASK        =    9
  253. ZBUFFER        =    10
  254. OPACITY        =    11
  255. LINEARKEY    =    12
  256. BINARYKEY    =    13
  257.  
  258. ----------------------------------------------------------------------
  259.  
  260. Addendum
  261. ========
  262.  
  263. The following information is an extension to the DEEP format
  264. proposed by TecSoft and used in their 24 bit paint application,
  265. TVPaint.  The extension provides an additional compression method
  266. and its associated chunk.
  267.  
  268. Additional compression type:
  269.  
  270. TVDC        =    5
  271.  
  272. Chunk ID:    TVDC    (TVPaint Deep Compression)
  273.  
  274. Chunk Purpose:
  275.  
  276. Provides the table of values required to enable decompression of
  277. the image data.
  278.  
  279. Chunk Description:
  280.  
  281. TVDC is a modified version of Delta compression, using a 16 word
  282. lookup table of delta values and also incorporates Run Length
  283. Limiting compression for short runs.
  284.  
  285. Note that the compression is made line by line for each element
  286. of the chunk DPEL.  For RGBA for example we have a Red line, a
  287. Green line, and so on.
  288.  
  289. CDepackTVDC(source,dest,table,size)
  290. UBYTE    *source;
  291. UBYTE    *dest;
  292. WORD    *table;
  293. int    size;
  294. {
  295. int    i;
  296. int    d;
  297. int    pos=0;
  298. UBYTE    v=0;
  299.  
  300.     for(i=0;i<size;i++)
  301.     {
  302.         d=source[pos>>1];
  303.         if(pos++&1) d&=0xf;
  304.         else d>>=4;
  305.         v+=table[d];
  306.         dest[i]=v;
  307.         if(!table[d])
  308.         {
  309.             d=source[pos>>1];
  310.             if(pos++&1) d&=0xf;
  311.             else d>>=4;
  312.             while(d--) dest[++i]=v;
  313.         }
  314.     }
  315.     return((pos+1)/2);
  316. }
  317.  
  318.